Skip to content

feat: register databases by key and validate paths at setup#52

Open
onehumandev wants to merge 1 commit into
silvermine:masterfrom
onehumandev:aldewaal/paths_support
Open

feat: register databases by key and validate paths at setup#52
onehumandev wants to merge 1 commit into
silvermine:masterfrom
onehumandev:aldewaal/paths_support

Conversation

@onehumandev

Copy link
Copy Markdown

Replace path-as-identifier IPC with explicit key registration so the frontend and Rust callers open databases by stable keys (e.g. "MAIN") instead of filesystem paths. Paths are resolved once in Rust during plugin setup, validated, and cached; later opens only look up the key.

Problems solved:

  • Security: untrusted frontend can no longer supply arbitrary paths over IPC; unknown keys fail with PATH_NOT_REGISTERED.
  • Cross-language identity: avoids TS/Rust path string mismatches (separators, symlinks, canonicalization) on every load.
  • Runtime path discovery: on_setup + SetupRegistrar register paths from app.path() / platform resolvers once, without repeat JNI or resolver work on each open.
  • Consistent open path: load, Connection::connect, and migrations share connect_to_database and the same DbInstances cache, along with assurance that migrations have completed before connecting to the database.
  • Safer registration: validate_database_path rejects relative paths, traversal, null bytes, and canonicalizes file paths at startup (fail-fast INVALID_PATH / PATH_TRAVERSAL).

API changes:

  • add_migrations(path, migrator)register_database(key, path, migrator?) (returns Result; adds Builder::on_setup / SetupRegistrar)
  • IPC/command args: dbdbKey; attached databasePathdatabaseKey
  • MigrationEvent: adds dbKey, dbPath is now absolute PathBuf
  • TransactionToken: dbPathdbKey
  • Connection trait on AppHandle for Rust-side opens by key

Also: expose canonicalize_database_path from conn-mgr, tighten is_memory_database query-param matching, add toolkit :memory: tests, update README/guest-js rustdoc, and add validate.rs (replaces load-time path resolution in resolve.rs).

@onehumandev onehumandev force-pushed the aldewaal/paths_support branch 2 times, most recently from ccf9564 to fe23ba5 Compare June 15, 2026 14:32
@onehumandev onehumandev marked this pull request as ready for review June 15, 2026 18:30
Comment thread api-iife.js Outdated
Comment thread src/validate.rs
Comment thread src/lib.rs Outdated
Comment thread guest-js/index.ts Outdated
Comment thread guest-js/index.ts Outdated
Comment thread src/lib.rs Outdated
Comment thread src/lib.rs
Comment thread src/lib.rs Outdated
Comment thread src/lib.rs
Comment thread src/lib.rs Outdated
@onehumandev onehumandev force-pushed the aldewaal/paths_support branch from fe23ba5 to bb03278 Compare June 15, 2026 19:11

@velocitysystems velocitysystems left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work carrying over the improvements from #50. Just a couple of observations:

  • Keys are now indirected to paths, and nothing dedupes them. Two keys pointing at the same file create two independent DbInstances pools over one store.
  • remove() is frontend‑reachable and deletes the file, orphaning the other key's live pool; close() can tear down a shared handle; per‑key migrations double‑run against one file.
  • For named shared‑cache :memory: URIs it's worse — closing one pool can destroy the in‑memory store the other key is still using.

Should we fail‑fast on duplicate canonical paths at register_database, or guard teardown by reverse‑indexing canonical paths?

Comment thread api-iife.js
Comment thread src/resolve.rs Outdated
@onehumandev onehumandev force-pushed the aldewaal/paths_support branch from bb03278 to 2db8db8 Compare June 15, 2026 21:02
@onehumandev

Copy link
Copy Markdown
Author

Great work carrying over the improvements from #50. Just a couple of observations:

  • Keys are now indirected to paths, and nothing dedupes them. Two keys pointing at the same file create two independent DbInstances pools over one store.
  • remove() is frontend‑reachable and deletes the file, orphaning the other key's live pool; close() can tear down a shared handle; per‑key migrations double‑run against one file.
  • For named shared‑cache :memory: URIs it's worse — closing one pool can destroy the in‑memory store the other key is still using.

Should we fail‑fast on duplicate canonical paths at register_database, or guard teardown by reverse‑indexing canonical paths?

Addressed here

Comment thread src/commands.rs Outdated
Comment thread guest-js/index.ts
Comment thread src/lib.rs
Replace path-as-identifier IPC with explicit key registration so the
frontend and Rust callers open databases by stable keys (e.g. "MAIN")
instead of filesystem paths. Paths are resolved once in Rust during
plugin setup, validated, and cached; later opens only look up the key.

Problems solved:
- Security: untrusted frontend can no longer supply arbitrary paths over
  IPC; unknown keys fail with PATH_NOT_REGISTERED.
- Cross-language identity: avoids TS/Rust path string mismatches
  (separators, symlinks, canonicalization) on every load.
- Runtime path discovery: `on_setup` + `SetupRegistrar` register paths
  from `app.path()` / platform resolvers once, without repeat JNI or
  resolver work on each open.
- Consistent open path: `load`, `Connection::connect`, and migrations
  share `connect_to_database` and the same `DbInstances` cache, along
  with assurance that migrations have completed before connecting to
  the database.
- Safer registration: `validate_database_path` rejects relative paths,
  traversal, null bytes, and canonicalizes file paths at startup
  (fail-fast INVALID_PATH / PATH_TRAVERSAL).

API changes:
- `add_migrations(path, migrator)` → `register_database(key, path, migrator?)`
  (returns Result; adds `Builder::on_setup` / `SetupRegistrar`)
- IPC/command args: `db` → `dbKey`; attached `databasePath` → `databaseKey`
- `MigrationEvent`: adds `dbKey`, `dbPath` is now absolute PathBuf
- `TransactionToken`: `dbPath` → `dbKey`
- `Connection` trait on `AppHandle` for Rust-side opens by key

Also: expose `canonicalize_database_path` from conn-mgr, tighten
`is_memory_database` query-param matching, add toolkit `:memory:` tests,
update README/guest-js rustdoc, and add `validate.rs` (replaces load-time
path resolution in `resolve.rs`).
@onehumandev onehumandev force-pushed the aldewaal/paths_support branch from 2db8db8 to 9af04de Compare June 16, 2026 16:21
@onehumandev onehumandev requested a review from jjhafer June 16, 2026 16:22
Comment thread src/validate.rs
})
}

#[cfg(test)]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The migration-by-key path still has no end-to-end test: no test registers a Migrator, connects by key, and asserts await_migrations blocked until Complete.

Should we add one to lock in the migrate-before-connect guarantee?

Comment thread guest-js/index.ts
/** Database path, the absolute path to the database file, such as
* `/var/lib/myapp/main.db`.
*/
public path: string;

@velocitysystems velocitysystems Jun 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should key and/or path be readonly? A caller overwriting either of these mutable properties would face unexpected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants